The forbidden empty state was a bare 'Access Restricted / Insufficient permissions'.
Replace with a reusable RestrictedState component: plain-language framing for a
non-k8s operator (states it's RBAC, not an empty cluster), and a 'How to get access'
disclosure with a generic ClusterRole/ClusterRoleBinding snippet + 'Copy request'
button to forward to whoever administers the cluster. Honest about cause (never
claims tier vs custom-role) and chart-version-agnostic (generic YAML).

Bugbot triage on the forbidden-state component:
- Expanded RBAC snippet could clip on short panes (absolute inset-0 centered,
  no scroll). Wrap in overflow-y-auto + min-h-full so it centers when collapsed
  and scrolls (no top clip) when expanded; cap the snippet at max-h-72.
- selectedKind.name is the API plural in normal use but a CRD deep-link can
  transiently carry the Kind (HTTPRoute) before discovery resolves it, yielding
  a snippet that wouldn't grant access. Only inline the resource when it looks
  like a valid lowercase resource name; otherwise use a <resource> placeholder
  and a generic role name.

Reframe the My Permissions dialog as 'Your access on this cluster' and add a
'Restricted resources' section: the kinds your RBAC can't list (from the
resource-counts forbidden set) shown as chips, with honest framing (an access
boundary, not an empty cluster) and a 'How to get access' link to the RBAC docs.
This is the comprehension anchor for the denied-vs-empty work — what you CAN do
(SelfSubjectRulesReview rules) alongside what's hidden and how to unblock.

…list 403

The main-panel restricted state keyed only off the list query returning 403, but
handleListResources returns 200 with [] for denied cluster-scoped kinds — so a
denied Node/PV fell through to 'No <kind> found' instead of 'Access Restricted',
the exact symptom this change set out to fix. Also trigger isSelectedForbidden
when the selected kind is in the counts forbidden set (which the backend now
populates for denied cluster-scoped kinds). Bugbot caught this.

resource-counts now tags each forbidden kind with a reason: 'rbac_denied' (Radar's
ServiceAccount can read the kind but the user's own RBAC can't — a user grant
surfaces it) vs 'unavailable' (no informer at all: not installed, SA lacks RBAC,
or feature off like rbac.viewRBAC — a user grant won't help).

RestrictedState branches on it: rbac_denied keeps the 'grant your identity' request
+ ClusterRole snippet; unavailable explains that Radar's ServiceAccount can't read
the kind and omits the (useless) user-grant snippet. Fixes the overclaim where
feature-disabled kinds (e.g. viewRBAC-off ClusterRoles) were told 'your RBAC
doesn't allow' with a snippet that wouldn't surface them.

Guards the counts-driven forbidden gate against a startup timing skew
where a kind is marked forbidden/unavailable in resource-counts before
its informer syncs, while the list query has since returned data. Actual
rows now win; a list 403 still forces the restricted state.